This repository was archived by the owner on Aug 3, 2024. It is now read-only.
Fix #548 by rendering datatype kinds more carefully #702
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Lovely! Thanks @RyanGlScott! Much better now! |
alexbiehl
pushed a commit
to alexbiehl/haddock
that referenced
this pull request
Feb 1, 2018
alexbiehl
pushed a commit
that referenced
this pull request
Feb 1, 2018
sjakobi
pushed a commit
to sjakobi/haddock
that referenced
this pull request
Jun 10, 2018
(cherry picked from commit 60e10eb)
This was referenced Jan 25, 2019
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Before, any data type that was loaded from an interface file (i.e., any data type that passes through
Haddock.Convert) was displaying utterly wrong kind information, leading to #548. For example, one can see this effect on themtlHaddocks on Hackage:Yuck! That return kind is utterly bogus, given that it also displays the type variables of
StateT.The simplest fix (adopted here) is to only display the return kind. Moreover, since we're dealing with data types here, I opt not to display the return kind if it's
*(since that is what it will be by default anyways).After this change, here is what
StateTlooks like now:(Haddock also now appears to render the kind signature of
m. I wasn't responsible for making that happen, but it's fortunate that Haddock does this, as it's important to ensure that the same kind information is still presented to the user.)